Suppressing Error Reporting

We receive our DOORS modules from a 3rd party. They are "read only" and some of them seem to have some kind of embedded trigger which attempts to access an include file from the PSToolbox. However, the majority of users on our end do not have the PSToolbox files and as a result, this generates an error whenever the module in question is opened. The error is a nuisance and doesn't prevent us from getting what we need done, but I was wondering if there was a work-around I could employ to try and sidestep the error message.

Does anyone know where I can acquire the deltabuff.inc file from the addins/PSToolbox/utensils/ directory?

I tried creating a dummy file containing nothing but a "halt" command on the off-chance that the file was being included in its entirety as a trigger, but this doesn't seem to be the case. I'm now getting messages that certain variables are undefined.
Zetareticuli - Tue May 18 15:19:11 EDT 2010

Re: Suppressing Error Reporting
Zetareticuli - Tue May 18 15:20:10 EDT 2010

Alternatively, if there's a way to suppress error output (the subject of this thread) that would accomplish my goal as well.

Re: Suppressing Error Reporting
SystemAdmin - Tue May 18 15:31:15 EDT 2010

You could try to use deltabuff.inc from <Your DOORS program directory>\lib\dxl\example\include

Re: Suppressing Error Reporting
Zetareticuli - Tue May 18 16:09:03 EDT 2010

SystemAdmin - Tue May 18 15:31:15 EDT 2010
You could try to use deltabuff.inc from <Your DOORS program directory>\lib\dxl\example\include

Excellent suggestion. It hadn't even occurred to me that the same file could exist elsewhere in the DOORS directory structure. I put the file in the expected location and the errors are gone. Thanks!

Re: Suppressing Error Reporting
llandale - Tue May 18 17:42:25 EDT 2010

.... Thus highlighting the problem with using #include statements in Layout and AttrDXL and Triggers. Tell your 3rd party to get the code and stick it ... directly into their Layout or AttrDXL, and don't use #include; or GADS use the 'diff' function instead. Or log in as the Administrator and remove the offending Layout/AttrDXL/Trigger.

Your solution requires everyone who opens the module to likewise deploy that file in that new directory on their PC.

If its a trigger, there may be a reasonable combination of module pre/post open/close triggers that, effectivly, disable other triggers, but it won't work for 'Standard' users since they cannot disable triggers.

Be advised that the deltaBuf algorithm is a candidate for 'Darwin Wan-a-be Awards', for those who understand that reference. (Folks doing humanity a favor by coming up with spectacularly unique and entertaining ways of taking themselves out of the gene pool...) Its sibling algorithm 'detalText' was significantly worse, and in fact had a bug such that you could only use it once per script (such as a simple Layout). They are many orders of magnitude slower than 'diff', as well as eating up such memory that everthing after them slows down as well. Having said that, 'diff' has an upper limit on how much it can compare, something like 10,000 words.

  • Louie

Yes, about 9 years ago I went through those algorithms and yes, at that time, I eventually got to understand them.